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ABSTRACT 



A method and apparatus for establishing and maintaining 
complex security rules is provided. The security rules are 
established through the use of "permission" classes that take 
advantage of the power and simplicity various features of 
object oriented programming, including the ability to inherit 
attributes and methods. For example, a permission super 
class is established that defines an interface to a validation 
method. A permission subclass may then be created which 
provides an implementation of the validation method. When 
invoked^ the validation method indicates whether a given 
permission represented by one object belonging to a per- 
mission class encompasses the permission represented by 
another object belonging to a permission class. Classes are 
also provided for grouping permissions into sets, and for 
establishing protection domains for classes of objects. 

24 Claims, 7 Drawing Sheets 
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TYPED, PARAMETERIZED, AND 
EXTENSIBLE ACCESS CONTROL 
PERMISSIONS 

RELATED APPLICATIONS 

The present application is related to U.S. patent applica- 
tion Ser. No. 08/988,431, entitled "CONTROLLING 
ACCESS TO A RESOURCE", filed by Li Gong, on the 
equal day herewith the contents of which are incorporated 
herein by reference. 

The present application is related to U.S. patent applica- 
tion Ser. No. 08/998,660, entitled "SECURE CLASS 
RESOLUTION, LOADING, AND DEFINITION", filed by 
Li Gong, on the equal day herewith the contents of which are 
incorporated herein by reference. 

The present application is related to U.S. patent applica- 
tion Ser. No. 08/988,439, entitled "PROTECTION 
DOMAINS TO PROVIDE SECURITY IN A COMPUTER 
SYSTEM", filed by Ii Gong, on the equal day herewith the 
contents of which are incorporated herein by reference. 

FIELD OF THE INVENTION 

The present invention relates to security mechanisms in a 
computer system. 

BACKGROUND OF THE INVENTION 

As the use of computer systems grows, organizations are 
becoming increasingly reliant upon them. A malfunction in 
the computer system can severely hamper the operation of 
such organizations. Thus organizations that use computer 
systems are vulnerable to users who may intentionally or 
unintentionally cause the computer system to malfunction. 

One way to compromise the security of a computer 
system is to cause the computer system to execute software 
that performs harmful actions on the computer system. 
There are various types of security measures that may be 
used to prevent a computer system from executing harmful 
software. One example is to check all software executed by 
the computer system with a "virus" checker. However, virus 
checkers only search for very specific software instructions. 
Many methods of using software to tamper with a comput- 
er's resources would not be detected by a virus checker. 

Another very common measure used to prevent the execu- 
tion of software that tampers with a computer's resources is 
the "trusted developers approach". According to the trusted 
developers approach, system administrators limit the soft- 
ware that a computer system can access to only software 
developed by trusted software developers. Such trusted 
developers may include, for example, well know vendors or 
in -house developers. 

Fundamental to the trusted developers approach is the 
idea that computer programs are created by developers, and 
that some developers can be trusted to not have produced 
software that compromises security. Also fundamental to the 
trusted developers approach is the notion that a computer 
system will only execute programs that are stored at loca- 
tions that are under control of the system administrators. 

Recently developed methods of running applications 
involve the automatic and immediate execution of software 
code loaded from remote sources over a network. When the 
remote sources include computer systems that are outside 
the control of system administrators, the trusted developers 
approach does not work. 

One attempt to adapt the trusted developers approach to 
systems that can execute code from remote sources is 



2 

referred to as the sand box method. The sand box method 
allows all code to be executed, but places restrictions on 
remote code. Specifically, the sand box method permits all 
trusted code full access to a computer system's resources 

5 and all remote code limited access to a computer system's 
resources. Trusted code is usually stored locally on the 
computer system under the direct control of the owners or 
administrators of the computer system, who are accountable 
for the security of the trusted code. 

*o One drawback to the sandbox approach is that the 
approach is not very granular. The sandbox approach is not 
very granular because all remote code is restricted to the 
same limited set of resources. Very often, there is a need to 
permit remote code from one source access to one set of 

15 computer resources while permitting remote code from 
another source access to another set of computer resources. 
For example, there may be a need to limit access to one set 
of files associated with one bank to remote code loaded over 
a network from a source associated with that one bank, and 

20 limit access to another set of files associated with another 
bank to remote code loaded over a network from a source 
associated with the other bank. 

Providing security measures that allow more granularity 
than the sand box method involves establishing a complex 

25 set of relationships between principals and permissions. A 
"principal" is an entity in the computer system to which 
permissions are granted. Examples of principals include 
processes, objects and threads. A "permission" is an autho- 
rization by the computer system that allows a principal to 

30 perform a particular action or function. 

Establishing sets of permissions for principals that may be 
received from multiple sources on a vast network, such as 
the Internet, typically requires developing complex security 
software. After such security software is developed, it must 
often be changed in order to meet changing security require- 
ments. Often, changing security requirements entail modi- 
fying permissions or creating new kinds of permissions. 
Typically, the security software of a computer system must 
be reprogrammed to incorporate these new kinds of permis- 
sions. Programming security software requires substantial 
effort and in-depth knowledge about a computer's security 
mechanisms and a computer's architecture. 
Based on the foregoing, it is clearly desirable to develop 

45 a method which reduces the effort and in-depth knowledge 
required to modify permissions established for the sources 
of code being executed by a computer system. It is further 
desirable to develop a method which reduces the effort and 
in-depth knowledge required to create new permissions. 

50 SUMMARY OF THE INVENTION 

A method and system for providing security using typed 
and extensible control permissions is provided. According to 
one aspect of the invention, the establishment and mainte- 

55 nance of complex security rules are enforced in a way that 
takes advantage of the power and simplicity of the inherit- 
ance feature of object oriented programming. 

Specifically, a "permission super class" is established 
from which subclasses may be created. Objects that belong 

60 to subclasses of the permission super class represent 
permissions, and are therefore referred to as permission 
objects. 

The permission subclasses inherit the methods and 
attributes of the permission super class. According to one 
65 embodiment, one of the methods defined by the permission 
super class and inherited by the permission subclasses is a 
validation method. Each permission subclass inherits the 



01/13/2004, EAST Version: 1.4.1 



6,047,377 

3 4 

validation method from the permission super class and DETAILED DESCRIPTION OF THE 

provides an implementation of the validation method. PREFERRED EMBODIMENT 

When the validation method is invoked for a particular / Almemodfland|a pr^ 

permission object belonging to a permission subclass, the is described L In 'thetollaiwr^fcscriplion; for the ; purposes c!? 

validation method indicates whether a given permission is 5 explanation? DUrner ous specific details are set forth in ordlR 

encompassed by the permission represented by the particular t0 prov ide a thorough understanding of the present invert) 

permission object. For example, the validation method of a t j orit i t be apparent, however, to one skilled in the arl 

permission object POl may be invoked to determine lhat the preS ent invention may be practiced without thesli 

whether the permission represented by another permission specific details. In other instances, well-known stractureS 

object P02 is encompassed in the permission represented by 1° and devices are shown j n Wock diagram form in order tfl\ 

POl, where both POl and P02 belong to classes that 4 a Vx)idfl Unn e;c ess^ 
descend from said permission super class. In this we can 

determine whether a permission to perform a first action, HARDWARE OVERVIEW 

represented by POl authorizes a request to perform a FIG. 1 is a block diagram that illustrates a computer 

second action which requires a second pennission repre- is m 1W which ^ embodiment of the 

sented by P02, by invoking the validation method of POl to be im lemented . Computer system 100 includes a bus 

determine whether the first permission represents an autho- m QT ^ communicatiorj mec hanism for communicating 

nzation to perform the requested second action. information, and a processor 104 coupled with bus 102 for 

According to another aspect of the invention, permissions processing information. Computer system 100 also includes 

represent actions on targets. Thus, a first permission object a ma i n memory 106, such as a random access memory 

can specify a first action and a first target, and a second (RAM) or other dynamic storage device, coupled to bus 102 

permission object can specify a second action and a second f or storing information and instructions to be executed by 

target. A determination is made of the whether the permis- processor 104. Main memory 106 also may be used for 

sion represented by the first permission object encompasses storing temporary variables or other intermediate informa- 

the permission represented by the second permission object t j on during execution of instructions to be executed by 

based on whether the first action implies the second action processor 104. Computer system 100 further includes a read 

and the first target implies the second target. In this we can on i y mem0 ry (ROM) 108 or other static storage device 

determine, for example, whether a permission to perform a coupled to bus 102 for storing static information and instruc- 

first action on a first target, represented by the first permis- tions for processor 104. A storage device 110, such as a 

sion object, authorizes a request to perform a second action magnetic disk or optical disk, is provided and coupled to bus 

on second target, which requires a second permission rep- 102 for storing information and instructions, 

resented by the second object, by determining whether first Computer system 100 may be coupled via bus 102 to a 

action implies the second action, and the first target implies display m ^ as a cathode ray tube (CR1) for displaying 

the second target. ^ information to a computer user. An input device 114, inciud- 

BRIEF DESCRIPTION OF THE DRAWINGS ing al P haDumeric and other kevs > * coupled to bus 102 for 

communicating information and command selections to 

The present invention is illustrated by way of example, processor 104. Another type of user input device is cursor 

and not by way of limitation, in the figures of the accom- control 116, such as a mouse, a trackball, or cursor direction 

panying drawings and in which like reference numerals refer 40 keys for communicating direction information and com- 

to similar elements and in which: mand selections to processor 104 and for controlling cursor 

FIG. 1 is a block diagram of a computer system on which movement on display 112. This input device typically has 

the present invention may be implemented; two degrees of freedom in two axes, a first axis (e.g., x) and 

FIG. 2 is a block diagram showing attributes and methods a Second axis f that aUows the device to 

associated with a permission super class and a subclass of 45 P osltlons in a P ane * 

the permission super class and permission obj ects belonging ^ invention is related to the use of computer system 100 

to the subclass of the permission super class in accordance for establishing typed permissions. According to one 

with one embodiment of the present invention; embodiment of the invention, establishing typed permis- 

F1G. 3 is a now chart showing the steps for establishing S10DS 15 pr ™ ded b ^ COm P Uter S ^ m 100 in res P 0nse to 

a permission super class and a subclass of the permission 50 prDCeSSOr , 10 f. ^8°" or more sequences of one or 

super class in accordance with one embodiment of the m ° re ^strucUons contained in main memory 106. Such 

> . instructions may be read into mam memory 106 from 

present invention; it 11, , , . 

. another computer-readable medium, such as storage device 

FIG. 4 is a block diagram outlining a security mechanism im Execution of the sequences of instructions contained in 

using permission objects in accordance with one embodi- 55 main memory 106 causeg processor 104 to perform the 

ment of the present invention; proccss steps describcd herein> Id alternative embodiments, 

FIG. 5 is a block diagram showing an exemplary policy hard-wired circuitry may be used in place of or in combi- 

n * e ; nation with software instructions to implement the inven- 

FIG. 6 is a block diagram showing a call stack associated tion. Thus, embodiments of the invention are not limited to 

with a thread and the protection domains containing per- 60 any specific combination of hardware circuitry and software, 

mission objects associated with the objects represented by The term "computer-readable medium" as used herein 

the call stack in accordance with one embodiment of the refers to any medium that participates in providing instruc- 

p resent invention; and tions to processor 104 for execution. Such a medium may 

FIG. 7 is a flow chart showing steps followed by a security take many forms, including but not limited to, non-volatile 

mechanism to determine whether a particular action is 65 media, volatile media, and transmission media. Non-volatile 

authorized in accordance with one embodiment of the media includes, for example, optical or magnetic disks, such 

present invention. as storage device 110. Volatile media includes dynamic 
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memory, such as main memory 106. Transmission media accordance with the invention, one such downloaded appli- 

includes coaxial cables, copper wire and fiber optics, includ- cation provides for establishing typed permissions as 

ing the wires that comprise bus 102. Transmission media can described herein. 

also take the form of acoustic or light waves, such as those -ph e received code may be executed by processor 104 as 

generated during radio-wave and infra-red data communi- 5 ^ is received, and/or stored in storage device 110, or other 

cations. non- volatile storage for later execution. In this manner, 

Common forms of computer-readable media include, for computer system 100 may obtain application code in the 

example, a floppy disk, a flexible disk, hard disk, magnetic form of a carrier wave, 
tape, or any other magnetic medium, a CD-ROM, any other 

optical medium, punchcards, papertape, any other physical 10 FUNCTIONAL OVERVIEW 

medium with patterns of holes, a RAM, a PROM, and A , , t . 1t - 

mr>r^xM i-t a on rnnnw *i_ i?> As mentioned above, systems that allow execution of 

EPROM, a FLASH-EPROM, any other memory chip or Ci c 3 , ,.„. ^ . , 

..J . ' , , . ' r software from remote sources present difficult security prob- 

cartridge, a earner wave as described hereinafter, or any , ™ A lL . . , i j4 f. 

it j. r * • . 4 , lems. Ine systems that nave been developed to address those 

other medium from which a computer can read. , , ' , Ci • • fi c t u 

r 15 problems are complex, otten requiring the use oi elaborate 

Various forms of computer readable media may be permission rules to deal with principals received from 

involved m carrying one or more sequences of one or more numerous sources. As the security needs of the systems 

instructions to processor 104 for execution. For example, the change ^ the permission rules must be updated by someone 

instructions may initially be earned on a magnetic disk of a who underst ands the complexities of the system, 

remote computer. The remote computer can load the instruc- A . . i ... 

. . r , . j j*u • * *• 20 According to one aspect of the invention, the complexities 

tions into its dynamic memory and send the instructions over . , & . . , , r t . . , ' , f 

i1L ,. . j a j 11. , associated with elaborate permission rules and systems are 

a telephone line using a modem. A modem local to computer , . , f - . t . * , 

. £\d\ ' ii_ j a iL * i i_ i * j reduced by making use of a powerful object-oriented con- 
system 100 can receive the data on the telephone line and - J t , & , ; 3 . 
J . - Ai Ul , , ,i j . . - , cept understood by most programmers, known as 
use an infra -red transmitter to convert the data to an in ixa-red «• . » * . u- t. i ■ 7- t. i 

t A . c , , ^ A i j * i_ * * inhentance , to establish relationships between classes of 

signal. An infra-red detector coupled to bus 102 can receive . . ™ , 

^ j * • j • • r j . , j * , . j i 25 permissions. The general concepts of obiect orientation, 

the data carried in the mira-red signal and place the data on f , . j f j m_j-a j ■ * 

u iai ™ mi ■ ,i j , i r 1Ar r inheritance and classes are described in Appendix L 

bus 102. Bus 102 carnes the data to main memory 106, from ^ r 

which processor 104 retrieves and executes the instructions. M shal1 be described in greater detail hereafter, a "per- 

The instructions received by main memory 106 may option- mission super class" is established from which subclasses 

ally be stored on storage device 110 either before or after mav be created. Objects that belong to subclasses of the 

execution by processor 104. 30 permission super class represent permissions, and are the re - 

^ . . 1 rm i * i j ■ fore referred to as permission objects. The permission sub- 
Computer system 100 also includes a communication t ■ . . it _ , , , ., , i\ t 
• . p ii© ij*u 1/mo classes inherit the methods and attnbutes of the permission 
interface 118 coupled to bus 102. Communication interface , . , rj ^ t . , , y 

118 provides a two-way data communication coupling to a ' ' ^ g ' vah f atlon ( m i 6thod f *»? h P«™^ 

network link 120 that ^connected to a local network 122. 35 "J^ 8 P r0V,deS an "npl^entation of the validation 

For example, communication interface 118 may be an inte- 
grated services digital network (ISDN) card or a modem to When lh& validation method is invoked for a particular 
provide a data communication connection to a correspond- permission object belonging to a permission subclass, the 
ing type of telephone line. As another example, communi- validation method indicates whether a given permission is 
cation interface 118 may be a local area network (LAN) card encompassed by the permission represented by the particular 
to provide a data communication connection to a compatible permission object. For example, the validation method of a 
LAN. Wireless links may also be implemented. In any such permission object POl may be invoked to determine 
implementation, communication interface 118 sends and whether the permission represented by another permission 
receives electrical, electromagnetic or optical signals that object P02 is encompassed in the permission represented by 
carry digital data streams representing various types of P01 > where 00111 p01 and P02 belong to classes that 
information. descend from said permission super class. 

Network link 120 typically provides data communication . Because the establishment and management of permis- 

through one or more networks to other data devices. For S10ns IS implemented around the class and inhentance 

example, network link 120 may provide a connection mechanism that is familiar to most programmers, permission 

through local network 122 to a host computer 124 or to data 50 management tends to be simpler and more intuitive. As the 

equipment operated by an Internet Service Provider (ISP) security needs of a system changes, the typed permission 

126. ISP 126 in turn provides data communication services s y stem provided herein allows easy modification to adapt to 

through the world wide packet data communication network me changes, without requiring specialized knowledge of 

now commonly referred to as the "Internet" 128. Local complex security-management techniques. 

network 122 and Internet 128 both use electrical, electro- cc „ 

PFRMTSSIONS 

magnetic or optical signals that carry digital data streams. ii^mynooj^i^ 

The signals through the various networks and the signals on As mentioned above, a permission is an authorization by 

network link 120 and through communication interface 118, tne computer system that allows a principal to perform a 

which carry the digital data to and from computer system particular action or function. According to one embodiment 

100, are exemplary forms of carrier waves transporting the 60 D f tne invention, permissions can be organized into catego- 

information. ries that correlate to categories of actions that are performed 

Computer system 100 can send messages and receive on computer systems. Each category is characterized by one 

data, including program code, through the network(s), net- or more attributes shared by all permissions belonging to the 

work link 120 and communication interface 118. In the category or subcategory. Attributes of each category include 

Internet example, a server 130 might transmit a requested 65 an action associated with the permission, and can include 

code for an application program through Internet 128, ISP various other attributes that further qualify the action 

126, local network 122 and communication interface 118. In attribute, such as a target attribute. A target is any entity, such 
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as a bank account, ^n^adult^I^^GtJannSlf or a computer mission class can have an action field which corresponds to 

resource (e.g. files, memory, printers, database records), to the action attribute, and a target field which corresponds to 

which an action is directed. the target attribute. 

For example, one common permission category is the file Each permission object contains fields with values corre- 

system permission category. A file system permission has an 5 sponding to attributes of a particular permission represented 

action attribute and a target attribute. The target is a par- by the permission object. For example, a given object 

ticular file or set of files upon which an action can be belonging to the FilePermission class can have an action 

performed. The action attribute is an action that can be field with a value representing a "write" action, and a target 

performed on a file, such as "writing" to a file. The target field with a value representing the directory "d:/". Io this 

attribute serves to further qualify the action by limiting the 10 example, the given object represents a permission to "write*' 

entities upon which the action can be performed. An to directory "d:/". 

example of a file system permission is an authorization to Note mat each permission ob j ec t is an instance of a 

"write" (i.e. the action) to a particular file like "/anyfile" (i.e. permission class. Likewise, a permission object and the 

the target). Note that in the examples provided herein, the permission it represents are said to represent an instance of 

file(s) and directory in which the file(s) is contained are 15 a permission category or subcategory, 
represented in a form recognized by those skilled in the art. 

Another example of a permission category is a bank THE PERMISSION SUPER CLASS 
account permission for a computer application used to 

manage bank accounts. Abank account permission can have Because all permissions share some common attributes, it 

an action attribute, an account attribute, and an amount 20 is useful and efficient to represent all categories of permis- 

attribute. An example of a bank account permission would slons Wlth one class that * a su P er class of a11 permission 

be an authorization to "withdraw" from bank account classes. The super class for all permission classes is herein 

"1233456" an amount of three dollars. referred to as the permission super class. Each permission 

Note that permissions categories can further comprise class is a subclass of the Permission super class, 

subcategories that are useful for organizing permissions. For 25 Tb e permission super class contains fields which repre- 

example, a subcategory of a bank account permissions can sent attributes common to all permissions. One such field is 

be permissions associated with a particular bank. an action field, which represents the action attribute com- 



IMPLIED PERMISSIONS 



mon to all permissions. 



In addition to sharing attributes, the permission super 
One permission can imply another. When one permission 30 class esta biishes a set of common methods that are useful for 
implies another permission, that one permission is said to and inherited by all permission objects, such as a get_action 
encompass the other permission. For example, a permission method. The common action method returns a value repre- 
to write to a directory, such "c:/", can imply a permission to senting the action field ^ implementation for the geL_ 
write to any file in the directory, such as "c:/thisfile". aclion me thod may be provided in the permission super 
Furthermore, an attribute of a permission can imply an 35 c i aS s. According to one embodiment, the implementation for 
attribute of another permission. For example, in some the get_action method simply returns the value of the action 
implementations, the action attribute of a permission to 
"write" implies an action attribute of a permission to "read". 

An amount attribute of a permission to withdraw three THE VALIDATION METHOD 

hundred dollars implies another attribute of a permission to 40 

withdraw two hundred dollars. In additiorl t0 implementing a set of common methods 

Usually, a permission encompasses another permission S ? ared ^ ? e ™ on subclasses, the permission super class 
when all the permission attributes of one permission imply ako e f es the ^™ to methods tha should be 
all the corresponding permission attributes of another per- fPP°**<L by every object but whose implementation 
mission. For example, a permission to "write" to file «d:/ 45 de P™ d * on the particular permission class of the object, 
somefile" implies a permission to "read" from file "d:/ ^ example of such method is a validation method that 
somefile" because a "write" implies a "read". However, a indicates whether a permission represented by one perrnis- 
permission to "write'' to file "d:/somefile" does not imply a sion ob i ect encompasses another permission represented by 
permission to "read" from file "d^otherfile" because "d:/ another permission object. As noted earlier, a permission 
somefile" does not imply "d:/otherfile , \ 50 typically encompasses another permission when each 

attribute of the one permission implies the corresponding 
REPRESENTING PERMISSIONS WITH attribute of thc olher 

permission. Because attributes of one 
CLASSES AND OBJECTS permission category may differ from attributes of another 

Using the techniques described herein, classes are used to permission category, the permission classes which represent 
represent categories of and subcategories of permissions, 55 permission categories may contain different sets of fields, 
and objects of those classes are used to represent the thus necessitating a different implementation of the valida- 
p articular permissions in a category or subcategory of per- tion method for some of the permission classes, 
missions. A permission represented by a class is herein Furthermore, the rules that govern whether a particular 
referred to as a typed permission. Classes used to represent attribute implies another attribute may vary from one per- 
categories of permissions are herein referred to as permis- 60 mission category to another. Hence, the implementation 
sion classes. Objects which belong to a permission class are required for the validation methods which carry out the rules 
herein referred to as permission objects. Furthermore, the can vary. 

fields of a permission class are used to represent the For example, the FilePermission permission class has an 

attributes of the category or subcategory of permissions action field and a target field. The target field could represent 
represented by the permission class. 65 a file or a set of files (e.g. "d:/somedirectory/somefile"). A 

For example, a FilePermission permission class can rep- permission class representing a bank account, 
resent the category of file system permissions. The FilePer- AccountPermission, can have an action field, an account 
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field, and a maximum amount field. The two permission 
classes, FilePer mission and AccountPer mission have a dif- 
ferent number attributes and different kinds of attributes. 

The rules governing whether one attribute of one permis- 
sion implies a corresponding attribute of another permission 5 
may differ from permission class to permission class as well. 
Specifically, the implementation of determining whether a 
permission for one set of files implies a permission for 
another set of files differs significantly from an implemen- 
tation that determines whether a permission for one maxi- 10 
mum amount implies another amount. It is worth noting that 
permissions of different permission classes usually cannot 
encompass each other. 

Although the implementation of some methods supported 
by all permission objects can vary from one permission class 15 
to another, the permission super class may be used to ensure 
that the result type of a method and its parameters can 
remain constant across all permission classes. Defining the 
interface to method in the permission super class without 
providing the implementation for the method establishes an 20 
interface that can be relied upon by all objects and object 
implementers (i.e. programmers) when interacting with per- 
mission objects. 

Those skilled in the art will recognize various techniques 
can be used to provide such an interface. One method would 25 
be to provide a super class with an abstract method that 
would be implemented by subclasses of the super class. 
Another method would be to provide a permission super 
class that defines a default implementation that subclasses 
can override. A default implementation can be, for example, 30 
to always return a value indicating that one permission is not 
encompassed by another permission. Another method uses 
Java Interfaces instead of abstract classes. 

CREATING TYPED PERMISSIONS 35 

Techniques for creating and using typed.permissions shalt 
now be desc rib ed~ with reference to the permission classes) 
shown in FIG. 2. The classes shown in FIG. 2 are used to 1 
create objects that represent permissions to manage access to! 40 
a television (TV). For purposes of illustration, assume that 
permissions associated with accessing a TV have an action 1 
attribute and a target attribute. The action attribute can either 
be to "watch", "enable", or "disenable" a channel. The target] 
attribute represents a particular channel. pj 45 

^veral examples of permission objects representing sevij 
eral TV permissions are shown in FIG. 2. Permission Object 
282 represents a permission to "disenable" "channel 5", arid 
permission objects 286 represents a permission to "watch 5 ' 
"channel 5". Permission object 282 and permission object 50 
286 are objects belonging to the subclass TV subclass 230. 
TV subclass 230 is a subclass of permission supefcclass,21j)! 

Referring to FIG. 3, in step 310 the attributes of the 
permission super class are established. In this example, an 
action field 222 is established for permission super class 55 
210. The action field 222 is a string data type. The action 
field 222 represents the permission attribute of any category 
of permission. 

In step 320, a validation method and other methods for a 
permission object are established. In this example, an 60 
abstract validation method 224 is provided. The validation 
method accepts as its first parameter an object reference of 
the data type (i.e. class) Permission class. Thus an object 
reference referring to an object belonging to any permission 
class is an acceptable parameter. The data type of the value 65 
returned by the method is Boolean. The Boolean value 
returned by the validation method indicates whether the 
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permission represented by the permission object referred to 
by the object reference is encompassed by the permission 
represented by the permission object whose validation 
method is invoked. For example, assume X and Y are 
permission objects. The method invocation X.Validation(Y) 
will return True if the permission represented by Y is 
encompassed in the permission represented by X, and False 
if the permission represented by Y is not encompassed in the 
permission represented by X. 

According to one embodiment, do implementation of the 
abstract validation method 224 is provided in permission 
super class 210. The implementation is left to the subclasses 
of permission super class 210. 

A get__action method is also provided in the permission 

super class 210. The get action method returns a string 

value representing the value contained in the action field 
222, An implementation is provided for the get_action 
method. The implementation merely returns the value of the 
action field as the return value of the get_action method. 

Th^s~e?skiUedJnjtoe 
and attributes can be provided. Only some of these methods 
and attributes have been illustrated in order to avoid unnec- 
e^^y^Meurings^ev tec^iqu^stde^nb^ilKr?irB^ 

An example code implementation of a permission super 
class 210 is illustrated below. Although the code example 
may resemble the JAVA programming language by Sun 
Microsystems Inc., the example is merely for illustrative 
purposes and is not meant to be representative of an actual 
code implementation. 



abstract class Permission { 

protected String action; 

abstract Boolean vaUdate(PermissioQ p); 



} 



ESTABLISHING PERMISSION SUBCLASSES 

In step 330, an implementation of the abstract validation 
method 224 is provided in the form of a validation imple- 
mentation 242 of a subclass of Permission super class 210. 
In this example, a TV subclass 230 is defined as a subclass 
of Permission super class 210. The implementation 242 of 
abstract validation method 224 includes code which, when 
executed, initially determines whether the object reference 
parameter refers to a permission object of same class as that 
of the permission object whose validation method is being 
invoked. 

When the classes of permission objects differ, one per- 
mission represented by a permission object does NOT 
encompass the permission represented by the other permis- 
sion object because a permission of one category does not 
encompass a permission of another category. For example, 
a TV permission does not encompass a file system permis- 
sion. 

Next, the code in the implementation 242 ensures that 
each attribute of the permission represented by the object 
reference is implied by each attribute of the permission 
represented by the object whose validation method is 
invoked. For example, if the action field and the target field 
of the permission object referred to by the object reference 
are identical to the action field and target field of the 
permission object whose validation method is invoked, then 
the validation method returns a true Boolean value. 
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In step 340, attributes and other methods of the TV 
subclass 230 are established. The other methods may include 
both new methods, and new implementations that override 
the implementations of inherited methods. In this example, 
a target field representing the target attribute of a TV 
permission is defined. A get_target method 246 is also 
provided. The get__target method simply returns a string 
value representing the channel attribute of the permission 
represented by the TV permission object. 

An example code implementation of the TV subclass 230 
is illustrated below. Although the code example may 
resemble the JAVA programming language by Sun Micro- 
systems Inc., the example is merely for illustrative purposes 
and is not meant to be representative of an actual code 
implementation. 



class TV extends Permission { 
protected String target; 

public string get_target() { 
return target; 

} 

TV(String a, String t){ 
action = a; 
target = t; 

} 

public Boolean validate(Permission p) { 
if (p instance of TV == false) 

return false; 
TV reqPerm = (TV)p; 
if (reqPenn.get_action() !- action) 

return false; 
if (reqPerm.get_target() != target) 

return false; 
return true 



} 



25 



30 



35 



40 



In step 350, the permission super class 210 and subclasses 
of the permission super class 210 are compiled and placed 
in a software library. Those skilled in the art are familiar 
with software tools and techniques used to compile the 
classes described above and to place them in software 
libraries. An example of such a tool is the Java Development 
Kit by Sun Microsystems Inc. 

Those skilled in the art will recognize that, in addition to 
the ones illustrated above, other attributes and methods are 
possible in permission subclasses. Only some these 
attributes and methods have been illustrated in order to 
avoid unnecessarily obscuring the techniques described 
herein. 

Furttffigrffii^^ 
to permission classes whose parent class is the permission 
super class 210. The techniques are applicable to subclasses 
of other permission classes which themselves are descen- 
dants of the permission super class. For example, it may be 
useful to provide a TV permission class, and then a subclass 
of the TV permission class that corresponds to a particular 
catfleTc*6mp:^y| 

PERMISSIONCOLLECTION OBJECTS 

In an embodiment of the invention, a Permission Collec- 
tion super class is provided to allow security administrators 
to easily manage sets of permissions. A PermissionCollec- 



45 



50 



55 



don class is used to create objects that each contain a set of 
zero or more permission objects. An object that is a subclass 
of the PermissionCollection super class is herein referred to 
as a PermissionCollection object. A PermissionCollection 
object manages a set of permission objects contained by the 
PermissionCollection object. A homogenous Permission- 
Collection object may only contain permission objects 
belonging to the same class, a heterogeneous Permission- 
Collection object may contain permission objects belonging 
to different classes. 

The PermissionCollection super class defines several 
methods. One method returns an enumeration of the per- 
mission objects contained in the PermissionCollection 
object. 

Another method, add_permission, adds a permission 
object to the set of permission objects contained in the 
PermissionCollection object. The add_permission method 
has a parameter of the type Permission. In the case of a 
homogenous PermissionClass object, for example, the 
method to add a permission object does not add a permission 
object if it is not of the same type (i.e. class) as any other 
permission object already contained in the PermissionCol- 
lection object. The method returns a Boolean flag indicating 
whether or not a permission object was added. 

A group validation method is another method defined by 
the PermissionCollectioD super class. The method accepts 
one parameter of the data type Permission. The method 
indicates whether or not any of the permissions represented 
by the permission objects contained in a PermissionCollec- 
tion object encompass the permission represented by the 
permission object specified by the parameter. The method 
processes each permission object by invoking each permis- 
sion objects validation method until either (1) the validation 
methods of all permission objects in the set have returned 
False or (2) a validation method for a permission object in 
the set returns True. 

A PermissionCollection object used to manage a set of 
permission objects can be created directly for the Permis- 
sionCollection super class, or from a subclass of the Per- 
missionCollection class. A subclass of the PermissionCol- 
lection super class can contain methods that provide 
functionality specific to a particular permission class. 

For example, a PermissionCollection object for FilePer- 
missions can provide an IsTargetlmplied method. The IsTar- 
getlmplied method indicates whether or not a particular 
target is implied by another target. For example, the method 
could syntactically determine whether "/sys/sysfile" is 
implied by "/sys/*". 

SECURITY USING "FINAL" DESIGNATION 

Many programming languages provide the keyword 
"final" to designate that something cannot be overridden. 
For example, if a class X is defined as final, then the 
compiler will generate an error if subsequent code attempts 
to define a subclass of class X. Alternatively, a class that is 
not final may have one or more methods that are declared to 
be final. For example, class Y may not be final, but class Y 
may define five methods, three of which are declared to be 
final. Under these circumstances, the compiler will allow 
subsequent code to define a subclass of class Y, but the 
subclass will inherit the three methods as is. The subclass 
will not be able to override the three inherited methods by 
defining alternative implementations for the methods. 

According to one embodiment of the invention, support 
for the "final" keyword is combined with permission classes 
to implement strong but flexible security mechanisms. For 
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example, assume that a first developer defines a FilePermis- executor is a Java virtual machine. A Java virtual machine 

sion subclass of the Permission super class. Assume further interprets code called byte code. Byte code is code generated 

that the Validation method for the File Permission class by a Java compiler from source files containing text. The 

returns True when the invoked permission is "write c:\*" and Java virtual machine is described in detail in Tim Undholm 

the input permission is "write c:\sys\config.txt". The first 5 & Frank Yellin, The Java Virtual Machine Specification 

developer may want to distribute the FilePermission class in (1996). 

a runtime library for use by other developers. For the purposes of explanation, it shall be assumed that 

If a user of the library is allowed to create a subclass of code from code stream 420 is object oriented software, 

the FilePermission class and override the validation method, Consequently, the code is in the form of methods associated 

the security policy programmed into the FilePermission i° with objects that belong to classes. One or more class 

logic may be compromised. For example, security would be definitions for a class are contained in code from code 

compromised if the validate method of the FilePermission stream 420. The fields and methods of the objects belonging 

class is overridden with logic that returns True when the to a class are defined by a class definition. These class 

invoked permission is "write c:\*" and the input permission definitions are used by code executor 410 to create objects 

is "write d:\ +, \ 15 which are instances of the classes defined by the class 

For the first developer, it may be critical for the applica- definitions, 

tions developed by the users of the runtime library to reflect These class definitions are generated from source code 

the same degree of security as is programmed into the written by a programmer. For example, a programmer using 

FilePermission logic. To prevent security loopholes, the first a Java Development Kit enters source code that conforms to 

developer may declare the FilePermission class to be final. 20 the Java programming language into a source file. The 

As a result, any user of the library would be unable to use source code embodies class definitions and other instruc- 

any security policies with respect to file access other than the tions which are used to generate byte code which controls 

security policies embodied in the original FilePermission the execution of a code executor (i.e. a Java virtual 

class. machine). Techniques for defining classes and generating 

While declaring the FilePermission class to be final will 25 code executed by a code executor, such as a Java virtual 

prevent security breaches, it limits the flexibility of the machine, are well known to those skilled in the art. 

library. For example, users of the library should be allowed Each class defined by a class definition from code stream 

to implement security policies with respect to file access that 420 is associated with a class name 438 and a code source 

are more restrictive than the FilePermission class policies. ^ 436. Code executor 410 maintains an association between a 

Thus, a user of the library may decide to implement a system class and its class name and code source. OTe^o^e^o^cejk 

that requires exact directory matches. In such a system represents a source of code from which is code received. Al 

"write c:\*" would encompass "write c:\hello.txt" but would "source of code" is an entity from which computer instrufcj 

not encompass "write c:\sys\joe. txt". tions are received. Examples of sources of code include a file 

To allow library users to enforce more restrictive security 35 or persistent object stored on a data server connected over a 

policies, the FilePermission class may be non-final, while all network, a FLASH_EPROM reader that reads instructions 

methods of the class but one are declared as final. The stored-ona-FLASHirEPROM^or-a-serof system-libraries^ 

non-final method, which may be called the AdditionalCheck "Thecbde source" maySTTcomposite recordcontaining a 

method, may be overridden by the library user. The Valida- uniform resource locator ("URL") 434 and set of public 

tion Method, which is final, may call the AdditionalCheck ^ cryptographic keys 432. A URL identifies a particular 

method as a final step to determine whether a particular source. The URL is a string used to uniquely identify any 

permission is encompassed by the invoked permission server connected to the world wide web. A URL may also be 

object. The Boolean value generated by the Validation used to designate sources local to computer system 100. 

Method logic are combined in a logical AND operation with Typically, the URL includes the designation of the file and 

the Boolean value generated by the AdditionalCheck method 45 directory of the file that is the source of the code stream that 

to produce the Boolean value that is ultimately returned by a server is providing. 

the Validation Method. A public cryp tographic key, herein referred to as a key, is 

Because the value returned by the Validation Method is used to validate the digital signature which may be included 

always false if the validation method logic is false, the in a file used to transport related code and data. Public 

security policy employed by the application developed by a 50 cryptographic keys and digital signatures are described in 

library user is at least as restrictive as those embodied in the Schneier, Applied Cryptography, (1996). The keys may be 

original FilePermission class logic. However, because the contained in the file, may be contained in a database 

library user is allowed to override the AdditionalCheck associating keys with sources (e.g. URLs), or be accessible 

method, the library user has the flexibility to implement using other possible alternative techniques, 

security rules that are more restrictive than the original 55 A dass may be associated with the digital signature 

FilePermission class logic. associated with the file used to transport code defining the 

EXEMPLARY SECURITY MECHANISM class > or ? e c !_ aSS ? ^ ni } ion of the C A iaS f mt l be s P ecificall y 

associated with a digital signature. A class that is associated 

An exemplary security mechanism illustrating one use of with a valid digital signature is referred to as being signed, 

typed permissions is shown in FIG. 4. Referring to FIG. 4, eo Valid digital signatures are digital signatures that can be 

the exemplary security mechanism includes a policy file verified by known keys stored in a database. If a class is 

444, a policy object 440, a domain mapper object 448, an associated with a digital signature which can not be verified, 

access controller 480, and one or more protection domains or the class is not associated with any digital signature, the 

482. The security mechanism is implemented using a code class is referred to as being unsigned. Unsigned classes may 

executor 410. 65 De associated with a default key. A key may be associated 

Code executor 410 executes code which code executor with a name, which may be used to look up the key in the 

410 receives from code stream 420. One example of a code database. 
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While one code source format has been described as represented by one or more files containing instructions. The 

including data indicating a cryptographic key and URL, instructions map code sources to permission objects which 

alternate formats are possible. Other information indicating represent the permissions authorized for the protections 

the source of the code, or combinations thereof, may be used domain corresponding to the code source. Each instruction 

to represent code sources. Therefore, it is understood that the 5 establishes a mapping between a particular code source and 

present invention, is not limited to any particular format for a particular permission object. An instruction represents one 

a code source. authorized permission for the objects belonging to the 

classes associated with the code source in the instruction. 

TRUSTED AND UNTRUSTED SOURCES The format of a typical instruction in the exemplary 

io policy file 444 is: 

The source of code stream 420 may be from zero or more (t . . „ TmT , . . . 

t . , , * j a~u> < permission xURLxkey namexpermission class 

untrusted sources 424 or zero or more trusted sources 428. ^ t' t t 

Untrusted sources 424 and trusted sources 428 may be file ™ T1Tir j , L , j- < ^ i 

• i j. «t , - <?.u w uurj The <URL> and the key corresponding to the <key name> 

servers, including rile servers that are part of the World Wide , , J ™ . * & . ■ 

„, , ' , % ^ . .i ▼ . i represent a code source. The key name is associated with a 

Web network of servers connected to the Internet. An „ , ™. , , j. , , 

. j • • ■ n * j.uj- * * 1 * 1 5 key. The key and corresponding key name are stored 

untrusted source is typically not under the direct control of * a. ■ tli u j * ,e j *i_ 

t , , c Jr t ' . ftA „ , - » together in a database. The key name can be used to find the 

the operators of computer system 100. Code from untrusted , • lL j . i_ ™ * • i 

. . . * j. key in the database. The permission class name> represents 

sources is herein referred to as untrusted code. , * . . . , ™ . . , , 

data identifying a permission class. The <action> and <tar- 

Because untrusted code is considered to pose a high get> ^presents data used to initialize (i.e. using an permis- 

secunty risk, the set of computer resources that untrusted 2Q sion object construct or) the action and target fields in a 

code may access is usually restricted to those which do not permission object belonging to the identified permission 

pose security threats. Code from a trusted source is code ckss Instruction 52 0-l in FIG. 5, for example, is an 

usually developed by trusted developers. Trusted code is authorization of a permission to write to any file in "Amp/*" 

considered to be reliable and pose much less security risk by any ob j ect of the class assoc i ate d with code source 

than remote code. ^ «fiie:// S omesource J, -"somekey" (i.e. URL-key name). 

Software code which is loaded over the network from a Referring to FIG. 4, in order to efficiently and conve- 

remote source and immediately executed is herein referred niently implement the policy and establish protection 

to as remote code. Typically, a remote source is a computer domains, policy object 440, domain mapper object 448, and 

system of another separate organization or individual. The one or more protection domain objects 482 are provided, 

remote source is often connected to the Internet. 30 Policy object 440 provides a mapping of code source to 

Normally untrusted code is remote code. However, code permission objects based on the policy file. Policy object 

from sources local to computer system 100 may pose a high 440 is initialized when code executor 410 is initialized. The 

security risk. Code from such local sources may be deemed policy object 440 parses the policy file 444. For each 

to be untrusted code from an untrusted source. Likewise, instruction, a permission object of the permission class 

code from a particular remote source may be considered to 35 designated in the instruction is created using the values of 

be reliable and to pose relatively little risk, and thus may be the action and target attributes that are designated in the 

deemed to be trusted code from a trusted resource. instruction. Finally, the permission object is mapped to the 

According to one embodiment of the invention, typed code source designated in the instruction, 

permissions are used in conjunction with protection domains While one method for representing the security policy of 

to implement security policies that allow trusted code to 40 computer system has been described, other methods are 

access more resources than untrusted code. A security policy possible. For example, a policy data base may contain fields 

thus established determines what actions code executor 410 ^at represent the code source, permission class, action and 

will allow the code within code stream 420 to perform. The tar S et - Therefore, it is understood that the techniques 

use of typed permissions and protection domains allows described herein are not limited to any specific method of 

policies that go beyond a simple trusted/untrusted 45 storin S a representation of security policy of a computer 

dichotomy by allowing relatively complex permission system. ^ 

groupings and relationships. f Noje -that even though the mstmcti bn^i llustrated -a bo.y^— 

n. ♦ j ■ j , j. contains data used to initialize two fields, a permission J~~ 

Protection domains and policies that may be used in ... . r . , . . u . « u '* 

- iU . j ■ • , u .1 "1 1 object may in fact have more or less than two fields , to 

conjunction with typed permissions shall now be described , . , , . . , 1 

in greater detail with continued reference to FIG. 4. 50 mim ^ For exa 7' e ' a bank lccount P em ™ ™jH have 

an action, account, and maximum amount attribute. When a 

PROTECTION DOMAINS AND POLICIES bank account permission object is initialized, the values in 

instruction corresponding to action, account, and maximum 

Protection domains are used to enforce security within amount attributesjwould be used to mitialize4he,perm^ion 

computer systems. A protection domain is a set of permis- 55 object! ***" " W 

sions granted to one or more principals. As described above, ^~The domain mapper object 448 contains a mapping 
permissions are represented by permission objects. between classes and protection domains objects. Protection 
Libraries, usually located in trusted sources, contain class domain objects 482 contain a set of permissions. Protection 
definitions for the permission super class 210 and permis- domain objects are associated with the permission objects 

sion classes. Typically these libraries are accessible by code 60 they contain, and with the classes to which a protection 
being executed by code executor 410. domain object is mapped to by domain mapper object 448. 

The correlation between permissions and principals con- Protection domain objects 482 are created when new 

stitutes the policy of the system. FIG. 4 illustrates an classes are received by code executor 410. When a new class 
exemplary policy implemented through use of a policy file is received, domain mapper 448 determines whether a 

444. A protection domain in this exemplary policy is defined 65 protection domain is already associated with the code 
as the set of permissions granted to the objects associated source. The domain mapper maintains data indicating which 
with a particular code source. The policy of the system is protection domains have been created and the code sources 
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associated with the protection domains. If a protection 
domain is already associated with the code source, the 
domain mapper adds a mapping of the new class and 
protection domain to a mapping of classes and protection 
domains maintained by the domain mapper 448. 

If a protection domain object is not associated with the 
code source of the new class, a new protection domain 
object is created and populated with permissions. The pro- 
tection domain is populated with those permission that are 
mapped to the code source of the new class based on the 
mapping of code sources to permissions in the policy object. 
Finally, the domain mapper adds a mapping of the new class 
and protection domain to the mapping of classes and pro- 
tection domains as previously described. 

In other embodiments of the invention, instead of storing 
the mapping of classes to protection domains in a domain 
mapper object, the mapping is stored as static fields in the 
protection domain class. The protection domain class is the 
class to which protection domain objects belong. There is 
only one instance of a static field for a class no matter how 
many objects belong to the class. The data indicating which 
protection domains have been created and the code sources 
associated with the protection domains is stored in static 
fields of the protection domain class. Alternatively, a map- 
ping between a class and protection domains associated with 
the class is stored as static fields in the class. 

Static methods are used to access and update the static 
data mentioned above. Static methods are invoked on behalf 
of the entire class, and may be invoked without referencing 
a specific object. 

EXEMPLARY ACCESS CONTROL 

An exemplary method using access controller 480 accord- 
ing to steps shown in FIG. 7 illustrates a use of permission 
objects. The calling stack, protection domains, and permis- 
sion objects shown in FIG. 6 are used as an example 
illustrating the performance of the steps shown in FIG. 7. 

A code executor, such as a Java virtual machine, main- 
tains for each thread or process a call stack of the object 
methods invoked by the thread or process. The call stack 
reflects the calling hierarchy between the methods that have 
been invoked but not yet completed by the thread or process. 
The call stack includes information identifying the objects 
with methods on the call stack. For example, assume that a 
thread executes a.x (where "a" is an object and "x" is a 
method associated with object "a"). Assume that a.x invokes 
b.y which invokes c.z. While c.z is executing, the call stack 
will contain data identifying a.x, b.y, and c.z. At this point, 
call stack 610, in FIG. 6, represents the calling hierarchy of 
the methods invoked by the thread but have not yet been 
completed by the thread. When the thread finishes execution 
of c.z, the data identifying c.z will be removed from call 
stack 610. 

Note that each object represented by the call stack is 
associated with a protection domain. Object a is associated 
with protection domain I and object b and object c are 
associated with protection domain J. Each protection 
domain object shown in FIG. 6 is associated with permission 
objects. The association between the objects, protection 
domain objects, and the permission objects is based on the 
a domain mapper object 448, policy object 440, policy file 
444, and constitutes the security policy with respect to the 
objects shown in FIG. 6. 

Assume that a thread invokes a.x, b.y, and c.z in the 
manner described so that call stack 610 is as it appears in 
FIG. 6. Referring to FIG. 7, assume that b.y requests an 
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action, the action being to "disenable" "channel-5". 
Typically, a request is in the form of an attempt to invoke a 
particular method that performs a particular operation. In 
this example, the particular request is made by object b. In 

5 other words, a method associated with object b invoked a 
method that may perform the particular action. 

Typically, access to a resource by code being executed by 
a code executor can only be made by invoking a resource 
manager. A resource manager is an object assigned the 

10 responsibility of managing access to its respective resource. 
In this example, object a is the resource manager. It is the 
resource manager, object a, that receives the request from 
object b. 

In step 754, the resource manager creates a permission 
15 object based on the permission required to perform the 
requested action. In this example, the permission required to 
perform this action is to "disenable" "channel-5". A permis- 
sion object belonging to TV subclass 230 is created based on 
the permission required, using "disenable" and "channel-5" 
20 as values for the action and target fields respectively. The 
permission required to perform a requested action is herein 
referred to as a required permission. The permission object 
created on the basis of the permission required is herein 
referred to as the required permission object. Control passes 
25 to step 760. 

DETERMINING WHETHER AN ACTION IS 
AUTHORIZED 

3Q In step 754, a request is received for a determination of 
whether the action is authorized. The determination is based 
on the permission required to perform the action. In this 
example, the resource manager invokes an access controller 
to determine whether the permission required is authorized 

35 for the entity requesting access. The access controller 
receives the request and a required permission object which 
was transmitted by the resource manager. 

In step 754, the validation methods of one or more 
permission objects is invoked in order to determine whether 

4Q an action is authorized based on the permission required. An 
action is authorized if every protection domain object asso- 
ciated with an object requesting a determination of whether 
an action is authorized contains a permission represented by 
a permission object that encompasses the required permis- 

4S sion for the action. 

The protection domains associated with an object request- 
ing the determination are the protection domain objects 
associated with each object represented by the calling hier- 
archy when the request was made. Any protection domain 

50 object associated with an object requesting a determination 
of whether an action is authorized is herein referred to as 
associated protection domain object. Finding the protection 
domain objects associated with a given object begins by 
determining the class of a given object. A code executor, 

55 such as a Java virtual machine, provides that each object 
incorporate a method which returns the class of an object. 
Next, the method of the class/domain mapper that returns the 
protection domain object associated with a class is invoked. 
For each of the associated protection domain objects, the 

60 validation methods of each permission object contained in 
the protection domain object are invoked passing in the 
permission required object as a parameter. The validation 
methods of each permission object contained in the associ- 
ated protection domain are invoked until a permission object 

65 indicates that the permission it represents encompasses the 
required permission. If none of the permission objects in a 
protection domain indicates that the permission the permis- 
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sion object encompasses the required permission, then the 
remainder of the associated protection domain objects are 
ignored. 

In this example, the access controller first determines the 
protection domain associated with the first object repre- 
sented on call stack 610, which is object a. The protection 
domain associated with object a is protection domain I. The 
validation method of the first permission object, permission 
object 282 (in FIG. 6), is invoked, passing in the required 
permission object as a parameter. As mentioned earlier, the 
required permission represented by the required permission 
object is a permission to "disenable" "channel-5". When the 
validation method of the first permission object is invoked 
the validation method indicates that the required permission 
is not encompassed. Next, the validation method of permis- 
sion object 286 (in FIG. 6) is invoked. The invocation of the 
validation method of permission object 286 indicates that 
the required permission is encompassed. 

The access controller then invokes the validation methods 
of the permission objects in the next protection domain 
object, protection domain object J, in the manner described. 
Each invocation of the validation methods of permission 
object 622 and permission object 626 indicates that the 
required permission is not encompassed. 

At step 764, a determination is made of whether the action 
requested was authorized. If every associated protection 
domain contains a permission object that represents a per- 
mission encompassing the required permission, then the 
requested action is authorized. When the requested action is 
authorized, control passes to step 768, where the action is 
performed before execution of the steps ceases. In this 
example, because not every protection domain object con- 
tained a permission encompassing the required permission, 
performance of the steps ends. The requested action is not 
executed. 

Typed permissions facilitate the establishment of new 
permissions. When a new category of permissions is desired, 
a new subclass is created. The particular rules or policy that 
govern whether the permissions granted a principal are 
encompassed by permission in the new category are imple- 
mented in the validation method of the new subclass rep- 
resenting permissions in the new subclass. 

Providing an abstract method for the determining whether 
a particular permission is encompassed by another estab- 
lishes an standard interface for determining whether a par- 
ticular permission represented by an permission object is 
encompassed by the permission represented by another 
permission object. The interface can be used and relied upon 
by any security mechanism. The security mechanisms that 
use the standard interface automatically effectuate rules or 
particular policy of a new permission category represented 
by the new subclass. 

In the foregoing specification, the invention has been 
described with reference to specific embodiments thereof. It 
will, however, be evident that various modifications and 
changes may be made thereto without departing from the 
broader spirit and scope of the invention. The specification 
and drawings are, accordingly, to be regarded in an iUus- 
trative rather than a restrictive sense. 

APPENDIX I 

OBJECT ORIENTATION AND INHERITANCE 

In object oriented programming, the world is modeled in 
terms of objects. An object is a record combined with the 
procedures and functions that manipulate it. All objects of a 
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class have the same fields, and are manipulated by the same 
procedures and functions ("methods"). An object is said to 
be an "instance" of the class to which it belongs. 

Sometimes an application requires the use of classes that 
5 are similar, but not identical. For example, the classes used 
to model both dolphins and dogs might include the fields for 
the nose, mouth, length and age. However, the dog class may 
require a hair color field, while the dolphin class requires a 
fin size field. 

10 To facilitate programming in situations in which an appli- 
cation requires multiple similar fields, object oriented pro- 
gramming supports "inheritance". Without inheritance, a 
programmer would have to write one set of code for the dog 
class, and a second set of code for the dolphin class. The 

15 code implementing the fields and methods common to object 
classes would appear redundantly in both classes. Duplicat- 
ing code in this manner is very inefficient, especially when 
the number of common fields and methods is much greater 
than the number of unique fields. Further, code duplication 

20 between classes complicates the process of revising the 
code, since changes to a common fields will have to be 
duplicated at multiple places in the code in order to maintain 
consistency between all classes that have the field. 

Inheritance allows a hierarchy to be established between 
classes. The fields and methods of a class automatically 
become fields and methods of the classes that are based upon 
the given class in the hierarchy. For example, an "animal" 
class may be defined to have nose, mouth, length and age 
fields, with associated methods. To add these fields and 
methods to the dolphin and dog classes, a programmer can 
specify that the dolphin and dog classes "inherit" the animal 
class. A class which inherits its fields and methods from 
another class is said to be a subclass of the other class. The 

35 other class, the class from which the subclass inherited its 
fields and methods, is said to be a parent class. In this 
example, the dolphin and dog classes are "subclasses" of the 
animal class, and the animal class is a parent class of the dog 
and dolphin classes. 

An The code for the inherited fields and methods is located in 
the parent class and is not duplicated in any subclasses. The 
subclasses only contain the code for fields and methods that 
supplement or override the fields and methods of the parent 
class. Consequently, all revisions to a parent class automati- 

45 cally apply to all subclasses. For example, if the field "age" 
is defined as an integer in the animal class and is not 
overridden in the dog and dolphin classes, then the dog and 
dolphin classes will include an integer to store an age value. 
If the animal class is revised so that "age" is defined as a real 

5Q number, then the dog and dolphin classes will automatically 
include a real number to store an age value. 

Note a third or greater level in a hierarchy of a classes can 
be established. A given class can inherit fields and methods 
of a class that is itself of a subclass of another class. A class 

55 above a particular class in a hierarchy is said be a super class 
to that particular class. Thus a parent class is a super class 
to its subclasses, and a super class to any class inheriting 
from a subclass of that parent class. 

METHODS AND ABSTRACT CLASSES 

60 

The methods of classes accept zero or more parameters. 
A class constructor, which is similar to a method, is used to 
initialize the fields of an object when objects belonging to 
that class are created. 
65 The code containing the instructions to perform the opera- 
tions associated with a method is said to be an implemen- 
tation of the method. A method may be defined for a class 
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without an implementation. A method with no implementa- 
tion is said to be an abstract method; a class which contains 
an abstract method is said to be an abstract class. 

Abstract classes are useful for establishing a common 
interface for the subclasses of abstract classes. The interface 
for an abstract method establishes the name of the method, 
the data type returned by a method and the data type of the 
method's parameters. The subclasses of an abstract class is 
responsible for providing the implementation of the abstract 
method. 

For example, assume that it is desired that all objects 
provide an interface which includes a method that indicates 
the number of legs an animal has. An abstract class, named 
animal, with an abstract method called get__legs that returns 
an integer representing the number of legs can be denned. 
Every subclass of the animal class would be responsible for 
providing code which implements the get_legs method for 
the particular type of animal represented by the subclass. For 
example, a cow subclass would provide a specific imple- 
mentation for get_legs that returned the integer four when 
the get_legs method of a cow object was invoked. 

The fields and methods of a class are defined by a class 
definition in software. Class definitions contained in soft- 
ware are typically created from source code usually received 
from a programmer. The source code is compiled into the 
code which can be executed by computer system 100. For 
example, a programmer using a Java Development Kit 
enters source code in the Java programming language into a 
source file. The source code embodies class definitions and 
other instructions which are used to generate byte code 
which control the execution of a Java code executor, a 
virtual machine. The JAVA™ virtual machine is described in 
detail in "The JAVA™ Virtual Machine Specification," by 
Tim Lindholm and Frank Yellin (Sun Microsystems, Inc.: 
Addison-Wesley Publishing Co.). The JAVA™ program- 
ming language is described in detail in "The JAVA™ 
Language Specification," by James Gosling, Bill Joy and 
Guy Steele (Sun Microsystems, Inc.: Addison-Wesley Pub- 
lishing Co.), and related texts in the JAVA™ Series pub- 
lished by Addison-Wesley. 

What is claimed is: 

1. A method for providing security, the method compris- 
ing the steps of: 

establishing a permission class; 

wherein each permission object that is a member of said 
permission class represents at least one permission to 
perform an action; 

wherein said permission class includes a validation 
method; and 

wherein said validation method, when invoked for a 
particular permission object belonging to said permis- 
sion class, indicates whether a specified permission is 
encompassed by a permission represented by the par- 
ticular permission object. 

2. The method of claim 1, wherein: 

the step of establishing a permission class includes estab- 
lishing a permission subclass that is a descendant of a 
permission super class; and 

the permission super class defines an interface of said 
validation method. 

3. The method of claim 2, further including the steps of: 
obtaining a first permission object, wherein said first 

permission object belongs to said permission subclass; 
obtaining a second object, wherein said second object 
belongs to a descendent class of the permission super 
class; and 
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determining whether a first permission represented by 
said first permission object encompasses a second 
permission represented by said second object by invok- 
ing a validation method associated with said first per- 
5 mission object. 

4. The method of claim 3, wherein the step of obtaining 
a second object includes obtaining a second object that 
belongs to said permission subclass. 

5. The method of claim 3, wherein the step of obtaining 
10 a second object includes obtaining a second object that 

belongs to a class that is different from said permission 
subclass. 

6. The method of claim 5, wherein: 

the method further includes the step of receiving a request 
15 to perform a particular action; and 

the step of obtaining said second object includes the step 

of obtaining said second object based on said request to 

perform said particular action. 

7. The method of claim 6, wherein the step of determining 
20 whether said first permission represented by said first per- 
mission object encompasses said second permission repre- 
sented by said second object includes sending to the vali- 
dation method of said first object data that identifies the 
second object. 

25 8. The method of claim 4, further including the steps of: 
obtaining a first permission object, wherein said first 
permission object belongs to said permission subclass, 
wherein said first permission object specifies a first 

30 action and a first target; 

obtaining a second object, wherein said second object 
belongs to a descendent class of the permission super 
class, wherein said second object specifies a second 
action and a second target; and 

35 determining whether a first permission represented by 
said first permission object encompasses a second 
permission represented by said second object by deter- 
mining whether said first action encompasses said 
second action and determining whether said first target 

40 encompasses said second target. 

9. The method of claim 3, further including the steps of 
obtaining a permission collection object associated with a 
plurality of permission objects, wherein said permission 
collection object includes a group validation method which, 

45 when invoked, indicates whether a specified permission is 
encompassed by at least one permission represented by said 
plurality of permission objects. 

10. The method of claim 3, wherein: 

the step of establishing a permission class includes estab- 
50 lishing a permission subclass that is a descendant of a 
permission super class; and 
the permission super class defines an interface of said 
validation method without providing an implementa- 
tion for said validation method. 
5S 11. A computer-readable medium carrying one or more 
sequences of one or more instructions for providing security, 
the one or more sequences of the one or more instructions 
including instructions which, when executed by one or more 
processors, cause the one or more processors to perform the 
60 steps of: 

establishing a permission class; 

wherein each permission object that is a member of said 
permission class represents at least one permission to 
65 perform an action; 

wherein said permission class includes a validation 
method; and 
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wherein said validation method, when invoked for a 
particular permission object belonging to said permis- 
sion class, indicates whether a specified permission is 
encompassed by a permission represented by the par- 
ticular permission object. 5 

12. The computer readable medium of claim 11, wherein: 
the step of establishing a permission class includes estab- 
lishing a permission subclass that is a descendant of a 
permission super class; and 

the permission super class defines an interface of said 
validation method. 

13. The computer readable medium of claim 12, further 
including one or more instructions for performing the steps 
of: 

obtaining a first permission object, wherein said first 15 
permission object belongs to said permission subclass; 

obtaining a second object, wherein said second object 
belongs to a descendent class of the permission super 
class; and 

determining whether a first permission represented by 2 q 
said first permission object encompasses a second 
permission represented by said second object by invok- 
ing a validation method associated with said first per- 
mission object. 

14. The computer readable medium of claim 13, wherein: 
the computer readable medium further includes one or 

more instructions for performing the step of receiving 
a request to perform a particular action; and 
the step of obtaining said second object includes the step 
of obtaining said second object based on said request to 
perform said particular action. 30 

15. The computer readable medium of claim 14, wherein 
the step of determining whether said first permission repre- 
sented by said first permission object encompasses said 
second permission represented by said second object 
includes sending to the validation method of said first object 35 
data that identifies the second object 

16. The computer readable medium of claim 12, further 
including one or more instructions for performing the steps 
of: 

obtaining a first permission object, wherein said first 40 
permission object belongs to said permission subclass, 
wherein said first permission object specifies a first 
action and a first target; 

obtaining a second object, wherein said second object 
belongs to a descendent class of the permission super 45 
class, wherein said second object specifies a second 
action and a second target; and 

determining whether a first permission represented by 
said first permission object encompasses a second 
permission represented by said second object by deter- 50 
mining whether said first action encompasses said 
second action and determining whether said first target 
encompasses said second target. 

17. The computer readable medium of claim 11, further 
including one or more instructions for performing the steps 

of obtaining a permission collection object associated with 55 
a plurality of permission objects, wherein said permission 
collection object includes a group validation method which, 
when invoked, indicates whether a specified permission is 
encompassed by at least one permission represented by said 
plurality of permission objects. so 

18. The computer readable medium of claim 11, wherein: 
the step of establishing a permission class includes estab- 
lishing a permission subclass that is a descendant of a 
permission super class; and 

the permission super class defines an interface of said 65 
validation method without providing an implementa- 
tion for said validation method. 
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19. A computer system comprising: 
a processor; 

a memory coupled to said processor; 

said processor being configured to establish a permission 
super class, wherein the permission super class defines 
an interface of a validation method; and 

said processor being configured to establish a permission 
subclass of the permission super class, wherein said 
permission subclass provides an implementation for 
said validation method, wherein said validation 
method, when invoked for a particular permission 
object belonging to said permission subclass, indicates 
whether a given permission is encompassed within a 
permission that is represented by said particular per- 
mission object. 

20. The computer system of claim 19, wherein the per- 
mission super class defines said interface of said validation 
method without defining any implementation of the valida- 
tion method. 

21. The computer system of claim 19, wherein: 

said processor is configured to create a first permission 

object in said memory; 
said first permission object belongs to said permission 

subclass; 

said processor is configured to create a second object in 
said memory, 

said second object belongs to a descendant class of the 
permission super class; and 

said processor is configured to determine whether a first 
permission represented by said first permission object 
encompasses a second permission represented by said 
second object by invoking a validation method associ- 
ated with said first permission object. 

22. The computer system of claim 21, wherein: 

said processor is configured to receive a request to per- 
form a particular action; and 

said processor is configured to create said second object 
by obtaining said second object based on said request 
to perform said particular action. 

23. The computer system of claim 22, wherein said 
processor is configured to determine whether said first 
permission represented by said first permission object 
encompasses said second permission represented by said 
second object by passing as a parameter to the validation 
method of said first object data that identifies the second 
object. 

24. The computer system of claim 19, wherein: 

said processor is configured to create a first permission 

object in said memory; 
said first permission object belongs to said permission 

subclass; 

said first permission object specifies a first action and a 
first target; 

said processor is configured to create a second object in 
said memory; 

said second object belongs to a subclass of the permission 
super class; 

said second object specifies a second action and a second 
target; and 

said processor is configured to determine whether a first 
permission represented by said first permission object 
encompasses a second permission represented by said 
second object by determining whether said first action 
encompasses said second action and determining 
whether said first target encompasses said second tar- 
get. 
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